Due to the proliferation of wireless networks, there are a continually increasing number of wireless devices in use today. These devices include mobile telephones, personal digital assistants (PDAs) with wireless communication capabilities, two-way pagers and the like. Concurrently with the increase of available wireless devices, software applications running on such devices have increased their utility. For example, the wireless device may include an application that retrieves a weather report for a list of desired cities or an application that allows a user to shop for groceries. These software applications take advantage of the ability to transmit data of the wireless network in order to provide timely and useful services to users, often in addition to voice communication. However, due to a plethora of different types of devices, restricted resources of some devices, and complexity of delivering large amounts of data to the devices, developing software applications remains a difficult and time-consuming task.
Currently, devices are configured to communicate with Web services through Internet-based browsers and/or native applications. Browsers have the advantage of being adaptable to operate on a cross-platform basis for a variety of different devices, but have a disadvantage of requesting pages (screen definitions in HTML) from the Web service, which hinders the persistence of data contained in the screens. A further disadvantage of browsers is that the screens are rendered at runtime, which can be resource intensive. Applications for browsers are efficient tools for designing platform independent applications. Accordingly, different runtime environments, regardless of the platform, execute the same application. However, since difference wireless devices have different capabilities and form factors, the application may not be executed or displayed as desired. Further, browser-based applications often require significant transfer bandwidth to operate efficiently, which may be costly or even unavailable for some wireless devices.
On the other hand, native applications are developed for a specific wireless device platform, thereby providing a relatively optimized application program for a runtime environment running on that platform. However, a platform dependent application introduces several drawbacks, including having to develop multiple versions of the same application and being relatively large in size, thereby taxing memory resources of the wireless device. Further, application developers need experience with programming languages such as Java and C++ to construct such native applications.
Current methods to register a wireless device (WD) with a mediator service (MS) usually are based on one of two approaches: pre-configured mediator or pre-configured application. Pre-configured mediator refers to a system where the mediator service needs to be pre-configured with information for the WD, and the mediator initiates the registration process. Pre-configured application refers to a system where an application on the WD must be configured with the information required to initiate registration, or this information must be provided by the user.
Disadvantages to the pre-configured mediator include the fact that the mediator service must be populated with the information to connect with all devices. One disadvantage is that the mediator service must initiate registration, but since a wireless device may be off, out-of-coverage, not loaded with appropriate client software, or inaccessible for any reason, the mediator service may have to try multiple times. If the device does not have the client software, the mediator service does not know how to retry once the device has the client software. If the device has an upgraded version of the registration process, due to memory and processing restrictions on a WD, it is desirable to limit the amount of backwards compatibility code required, and in the situation where the mediator initiates registration, the device may need a certain amount of backwards compatibility support. Having the device initiate registration will put this burden on the MS, which typically has much more resources to handle this.
Disadvantages to the pre-configured application include the fact that this would require that the application definition would require the identification information for the MS, or at least have an associated configuration file. Either way of changing the MS identification in order to switch MS' would require an application or file update. This would cost in either information technology (IT) personnel time or over-the-air (OTA) wireless charges. Alternatively the identification information might be provided by the user. This is less user-friendly, IT personnel has less control over the device, and introduces user error.